Deprecate abstract coroutine context keys #4522
Conversation
Additionally, removed the outdated opt-ins into experimental standard library APIs, as those are all stable now. Fixes #4333
|
Just to clarify, you will also make a twin PR into stdlib to deprecate |
|
@murfel, yes, but these are independent tasks. |
| AbstractCoroutineContextElement(ContinuationInterceptor), ContinuationInterceptor { | ||
|
|
||
| /** @suppress */ | ||
| @Deprecated("Use ContinuationInterceptor.Key and attempt " + |
There was a problem hiding this comment.
That's a bit of a nuisance.
I would consider coupling this change with introduction of .dispatcher and .dispatcherOrNull extensions on CoroutineContext (not sure about the CoroutineScope).
There was a problem hiding this comment.
I see what you mean, but this pattern is very niche anyway: https://grep.app/search?f.lang=Kotlin®exp=true&q=%5B%5E+%5D%5C%5BCoroutineDispatcher%5C%5D
In addition, in most cases, using ContinuationInterceptor instead of CoroutineDispatcher doesn't make any functional difference (or even makes the code a bit more flexible), which means directing the few existing cases to .dispatcher is not ideal.
There was a problem hiding this comment.
I've figured, but still see it as a good idea:
- That's, generally, an informal respect to backwards compatibility and migration paths (i.e. not how we did it with
capitalize) for users who do use that - The cost of this addition is negligible
- In the spirit of the standard library, it is a small but really convenient addition when you need it. I believe even I was in need of that quite a few times (I was also pretty sure I created an issue for that, but I failed to find it)
Additionally, removed the outdated opt-ins into experimental standard library APIs, as those are all stable now.
Fixes #4333